1. Field of the Invention
Embodiments of the invention relate generally to an application programming interface (API) for performing physics simulations. More particularly, the invention relates to an API for performing cloth simulations.
2. Description of Related Art
An Application Programming Interface (API) is a set of definitions and/or protocols used to generate computer software applications (hereafter, applications). In general, an API defines how an application communicates with other software in a computer system. For example, an API may define how an application accesses (e.g., invokes, calls, references, modifies, etc.) a set of software components (e.g., functions, procedures, variables, data structures, etc.) in the system. Alternatively, an API may also define how an application interacts with a piece of software such as an interpreter (e.g., a JavaScript Interpreter).
An API typically takes the form of a set of “calls”, data structures, and variables that can be included in an application. The term “call” is used herein to denote any part of an application (e.g., an instruction, a code fragment, etc.) causing initiation, execution, retrieval, storage, indexing, update, etc. of another piece of software. In other words, including a particular call in an application generally causes the application to access a software component associated with the call. The term “data structure” should be broadly read to encompass various types of data, including single parameters and variables, as well as references, software objects, and so forth.
The term “application” is used throughout this written description to describe any piece of software that enables at least one function in a computational platform. For example, an application typically comprises a data file that enables some function by providing a set of instructions for performing the function. Applications can also be designed to have hierarchical relationships with other applications. For example, one application may control or initiate the execution of another application, or some portion thereof. In such cases, terms such as “main application” and “secondary application” may be used to describe this hierarchical relationship. However, those skilled in the art will recognize that these designations are somewhat arbitrary, e.g., as main and secondary applications may exert mutual control over each other, and also, such applications often function in the context of some greater execution hierarchy.
The terms “routine” and “subroutine” are used to denote a part of an application smaller than the whole application. Each routine or subroutine in an application may comprise one or more subroutines and/or one or more calls to other software components as previously defined in this specification.
A classic example of a call included in an application is a “function call”. A function call generally comprises a name of a function and zero or more parameters or arguments for the function. When an application including the function call is executed, the function is invoked with its accompanying arguments.
The set of software components that can be accessed using a particular API is referred to as the implementation of the API. The implementation of an API may include, for example, a software library designed to run on a particular system. In general, an API is not bound to any one particular implementation. In fact, an application may be written using a particular API so that the application may be ported to systems with different implementations of the API. For instance, an API defined by the Open Graphics Library (OpenGL) standard allows programmers to write graphics applications that run on both UNIX and Windows based platforms, even though the underlying implementation of the API is different on each platform.
In general, the implementation of one API can be constructed with calls from another API. For example, an API defining complex high-level functions can be implemented using API calls defining intermediate-level functions. The API defining intermediate-level functions can be implemented using API calls defining low-level functions, and so on.
The implementation of most APIs is distributed in one of two ways. The first way is to include the implementation as part of a computer's operating system. For example, the implementation could comprise a set of code libraries distributed with the operating system. The second way is to distribute the implementation as a separate application or as an executable or a code library that has to be linked with and/or compiled with an application.
In some cases, source code for an API's implementation is available for viewing and modification. Where an API's implementation is available in this way, the API is called “open source”. In other cases, the API is only available as a set of binary files or the like, and hence, the only way to access the API is by including calls defined by the API in an application.
The term “software development kit” (SDK) is often used interchangeably with the term “API” because a SDK comprises a set of tools (e.g., an API) used to create software applications. However, a SDK generally comprises additional tools for developing applications besides an API. For instance, a software development kit may include utilities such as a debugger, or it may include special hardware tools used to communicate with embedded devices.
Most operating systems provide APIs that allow application programmers to create and/or control various system objects, such as display graphics, memory, file systems, processes, etc. In addition, operating systems may also provide APIs for performing common tasks such as multimedia processing, networking functions, and so forth.
Many independent software and/or hardware applications also provide APIs that allow application programmers to interface (e.g., control, communicate, etc.) with them. For example, an API used for communicating with a peripheral device such as a camera may define calls used to access low level software for adjusting specific aspects of the camera such as its aperture, shutter speed, exposure time, etc.
FIG. 1 is a conceptual illustration of a software architecture 100 for a system including an API. In FIG. 1, a plurality of applications 101 access a plurality of software components (API routines) 104 using an API 102. API routines 104 form a part of the implementation of API 102 and are located in an operating system or application 103.
FIG. 2 is a conceptual illustration of a conventional system 200 used to run applications containing calls from an API 205. In this written description, the term “run” describes any process in which hardware resources associated with a computational platform perform an operation under the direction (directly or indirectly) of a software resource.
Referring to FIG. 2, system 200 comprises a central processing unit (CPU) 201 operatively connected to an external memory 202. External memory 202 stores an application 203, API 205, and a plurality of API routines 206. Application 204 invokes API routines 206 using API calls 204 defined by API 205. As indicated by broken boxes in FIG. 2, application 204 and API routines 206 run on CPU 202.
Using an API to write applications is advantageous for various reasons. For example, a good API generally provides a level of abstraction between an application programmer and the low level details of the software components called by the API. An API also generally provides access to commonly used functionalities (e.g., creating display graphics, formatting text, spawning processes) so that application programmers do not have to implement these functionalities from scratch. Moreover, since an API is not bound to a particular implementation, APIs generally allow applications to be ported between different systems. In addition, APIs provide standard representations for various programming tasks, which allows different programmers to work on an application without having to relearn all the calls contained therein.
Because of the various advantages provided by APIs, most specialized application areas in the field of computer science/engineering have associated APIs. The calls provided by an API serve as building blocks for creating applications of increasing complexity within the application area. For example, in computer graphics, low level APIs such as OpenGL and DirectX define functions for rendering primitive graphics components such as polygons and other shapes. Graphics programmers such as video game programmers then build upon the functions defined by the low level APIs to create higher level APIs defining functions for performing higher level tasks such as complex character animations. Accordingly, developing effective APIs increases the scope of what can be produced by application programmers within an application area.
An emerging application area where APIs are still in the primitive stages of development is the area of computational physics simulations. Computational physics simulations are used for a variety of purposes, ranging from scientific visualization to three dimensional (3D) game animation.
The goal of computational physics simulations is to model interactions between objects in a virtual world using the laws of physics. For example, in the case of scientific visualization, the physical forces and interactions between the elements of a polypeptide chain may be computationally modeled and observed in order to predict the conformation (e.g., folding) of a particular protein. In the case of 3D game animation, the physical forces and interactions between actors (e.g., characters, objects, substances, etc.) in a scene and their environment is modeled in order to generate lifelike animations of the scene. Simulations of forces such as gravity, pressure, friction, chemical forces, etc. can be combined to create lifelike animations of collisions, falling objects, explosions, and so forth.
Formally defined, a “physics simulation” is a virtual representation of a physical entity or entities that changes over time in accordance with the laws of physics. For example, FIG. 3 illustrates a physics simulation wherein a “world state” 301 is periodically updated according to a step function 302 to yield an “updated world state” 303. World state 301 typically includes a set of objects having a number of associated physical attributes such as a size, shape, mass, location, velocity, acceleration, density, etc. World state 301 also typically includes a set of forces acting on each of the objects. The forces may include, for example, gravity, pressure, friction, magnetic attraction/repulsion, etc. In step function 302, the objects are allowed to evolve, i.e., change physical attributes, for a predetermined time step in accordance with their associated velocities, forces, etc. A resulting new set of physical attributes and forces constitute updated world state 303. Step function can then be repeated to generate further world states from updated world state 303.
An example of a conventional API designed to execute physics simulations is Havok Physics 3 (HP3). HP3 defines routines for performing collision detection, dynamics and constraint solving, and vehicle dynamics in a physics simulation. One interesting problem that currently available APIs fail to adequately address is the problem of simulating cloth using physics.
In general, a piece of cloth can be simulated by representing the cloth as a collection of primitive elements such as particles, geometric forms such as polygons, or nodes or vertices in a mesh. Each primitive element typically has an associated set of physical attributes such as size, mass, velocity, location, and a set of forces acting on it. In addition, the primitive elements typically have constrained interrelationships. For example, the locations of primitive elements representing adjacent units of a simulated piece of cloth may be correlated under a set of constraints to represent cloth properties such as topology or interconnectedness, stretchiness, rigidity, and so on. Furthermore, attributes related to the appearance of a piece of cloth, such as texture and other material properties, can also be simulated for display purposes.
FIG. 4 illustrates one example of how a cloth simulation may be performed. Referring to FIG. 4, a set of physical attributes and forces associated with a simulated piece of cloth can be said to constitute a cloth state 401. A step function 402 acts on the cloth for a predetermined time step so that the cloth evolves in accordance with velocities, forces, and other constraints associated with each primitive element constituting the cloth. Accordingly, an updated cloth state 403 is generated after the predetermined time step.
In most practical scenarios, the cloth simulation is coupled to an output for displaying or evaluating properties of the simulated cloth. For example, in FIG. 4, updated cloth state 403 is transformed into an image 405 by a display function 404. In general, display function 404 performs a mapping between a three dimensional representation of the cloth and a two dimensional representation. A variety of methods could be used to perform display function 404. For example, projective transformations, ray trace algorithms, hidden surface removal functions, and a wide variety of other rendering techniques could be used to form image 405.
By providing an effective API, cloth simulations can be more readily introduced into contemporary applications such as cutting edge interactive video games. An effective API would give application programmers access to complicated functions, data structures, and definitions required to perform cloth simulations with minimal additional programming overhead.